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ABSTRACT 

In  cooperation  with  EDA  (European  Defence  Agency),  EU  Core  Technical  Framework  Study  was 
conducted  during  2008-2009.  The  goal  of  the  study  is  to  enable  a  framework  that  promotes  secure, 
multinational  distributed  simulations.  The  main  domains  targeted  are  Training,  Simulation  Based 
Acquisition  (SBA)  and  Concept  Development  and  Experimentation  (CD&E).  On  developing  such  a 
framework,  efforts  have  been  made  to  reuse  the  existing  state-of-the-art  methods  and  techniques  without 
reinventing  the  wheel,  which  would  increase  usability  and  acceptance  of  the  framework. 

This  paper  gives  an  overview  of  the  Core  Technical  Framework  developed  during  the  study  and  then 
presents  a  part  of  the  results  in  more  detail,  i.e.  semantic  mapping  among  the  M&S  and  Systems 
Engineering  standards.  The  mapping  has  been  made  between  the  specification  documents  produced  from 
the  standards.  Such  a  mapping  contributes  to  increased  communication  between  different  types  of 
stakeholders,  reuse  of  M&S  artefacts  and  interoperability. 
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1  INTRODUCTION 

Typically  system  development  including  simulation  model  development  and  its  intended  deployment 
needs  to  be  performed  by  considering  a  number  of  different  aspects  from  different  stakeholders  with 
different  responsibility  and  interests.  In  the  past  these  different  stakeholders  usually  had  their  own 
methods,  representation  languages  and  terms  to  describe  their  parts  of  the  system  from  their  perspectives 
which  fit  for  their  own  purpose.  Three  major  problems  with  this  way  of  working  are: 

•  It  is  difficult  for  the  different  stakeholders  involved  to  communicate  with  each  other  in  efficient 
manner  due  to  lack  of  common  base. 

•  It  is  difficult  to  establish  a  holistic  view  of  the  whole  system. 

•  Consequently,  verification  and  validation  (V&V)  can  not  be  conducted  effectively  or  efficiently. 

An  architecture  framework1  provides  a  collection  of  views  each  of  which  is  intended  to  describe  different 
parts  and  aspects  of  a  system  from  the  viewpoints  of  different  stakeholders.  Using  an  architecture 
framework  each  of  the  stakeholders  can  express  his/her  concerns  in  terms  of  views  in  a  manner  consistent 
and  communicative  with  other  views  that  are  also  provided  by  the  same  framework,  and  that  describe 
other  stakeholders’  concerns.  Further,  system  descriptions  captured  in  such  views  can  be  reused  within 
current  or  future  projects.  Thereby  an  holistic  and  consistent  description  of  a  complex  problem  from 
different  perspectives  can  be  achieved,  ensuring  traceability  between  the  developed  distributed  simulation, 
various  tactics,  techniques,  procedures,  strategy  or  doctrinal  guidance,  system  and  organizational 
processes  and  functions  etc.  Further,  it  ensures  all  participating  stakeholders  develop  a  common 
understanding  of  the  problem  in  focus,  e.g.  organizational  and  system  capability. 

One  may  say  that  architecture  framework  approaches,  e.g.  MODAF  (Ministry  of  Defence  Architecture 
Framework),  DoDAF  (Department  of  Defence  Architecture  Framework)  and  NAF  (NATO  Architecture 
Framework),  originate  from  the  Systems  and  Software  Engineering  (S/SE)  community.  Nevertheless  we 
claim  that  architecture  frameworks  are  equally  applicable  to  M&S  as  well  for  at  least  two  reasons: 

•  M&S  can  be  considered  as  a  subset  of  S/SE.2 

•  Architecture  framework  can  be  preferably  used  as  a  hub  to  create  an  alignment  among  the  M&S 
and  S/SE  approaches  (standards,  methods,  techniques). 

Section  2  provides  an  overview  of  the  proposed  Core  Technical  Framework  which  contains  among  others 
the  mapping  between  Systems  Engineering  and  M&S  as  a  subcomponent.  Section  3  contains  a  general 
discussion  about  architecture  and  architecture  framework.  Then  the  mapping  is  presented  in  detail  in 
Section  4,  and  final  remarks  are  made  in  Section  5. 


2  OVERVIEW  OF  THE  CORE  TECHNICAL  FRAMEWORK 

2.1  Purpose 

The  purpose  of  the  EU  Core  Technical  Framework  Study  has  been  to  define  an  EU-wide  Distributed 
Simulation  Architecture  enabling  secure,  cost-efficient,  multinational,  distributed  simulation 
experimentation  and  training  across  the  participating  member  states  (pMS). 


1  “Architecture  framework”  and  “architecture”  will  be  defined  in  Section  3. 

2 

We  are  aware  that  this  may  be  a  very  strong  statement.  There  are  M&S -specific  issues  indeed  that  are  not  covered  sufficiently 
in  S/SE.  For  example,  VV&A  in  M&S  and  S/SE  are  different  from  each  other.  What  we  mean  is,  from  the  system  viewpoint, 
a  simulation  model  is  a  system  as  well. 
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The  main  benefit  of  a  Core  Technical  Framework  is  to  promote  reuse  of  earlier  simulation  efforts,  to 
support  collaborative  efforts,  to  ensure  interoperability  and  to  provide  methods,  capabilities  and  technical 
solutions  to  enable  cost  effective  use  of  distributed  simulations  in  the  whole  lifetime  cycle. 

2.2  Scope  and  Effect 

Constructing  an  EU  Core  Technical  Framework  is  not  a  simple  task  due  to  the  increasing  complexity  of 
the  operative  environment  and  the  diversity  of  distributed  simulations  that  now  need  to  be  integrated. 

The  operations  of  today  are  characterized  by  the  collaboration  of  a  growing  number  of  players,  in  a  multi¬ 
national  environment  with  different  organizations,  methods,  technologies  and  policies  &  regulations.  Such 
Multi-Dimensional  Mission  Operations  (MDMO)  is  ranging  from  non-military  tasks  as  humanitarian 
relief  operations  or  crisis  management  activities  to  pure  military  operations. 

Peace-keeping/enforcement  operations  are  examples  of  such  operations,  which  are  conducted  by  joint 
military  forces  from  different  allied  countries  acting  together  for  the  accomplishment  of  a  common 
strategy  through  partnership,  cooperation  and  interaction  beyond  national  borders.  Combined  operations, 
e.g.  humanitarian  relief  operations,  which  may  include  cooperation  with  civilian  organizations,  such  as 
local  government,  police  and  non-governmental  organizations  like  the  Red  Cross  are  also  needed. 

These  operations  benefit  from  a  wide  distributed  simulation  capability,  which  enables  joint  acquisition, 
training,  execution,  examination  and  evaluation  in  order  to  handle  complex  situations  and  achieve 
operational  effects.  Design,  planning,  performance  and  evaluation  of  distributed  simulations  are,  however 
a  complex  task  where  multiple  dimensions  of  complexity  need  to  be  covered. 

This  study  encompasses  distributed  simulations  in  the  domains: 

•  Concept  Development  &  Experimentation  (CD&E)  utilizes  the  joint  network  of  connected  real- 
world  and  simulated  systems  to  investigate  and  develop  requirements  on  technical  systems, 
doctrines  and  operational  processes; 

•  Simulation  Based  Acquisition  (SB A)  for  material  procurement  or  capability  development  can  be 
performed  in  an  cost-effective  way  through  the  availability  of  real-world  systems  and  simulators 
in  a  net-centric  environment; 

•  Joint  and  Combined  Distributed  Training  at  different  operational  levels,  to  achieve  a  functional 
and  effective  organization  using  live  systems  connected  to  simulator  systems  and  training  centres. 
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Figure  1 :  Distributed  simulations  and  domains  [1] 

By  using  distributed  simulations  EU  participating  member  states  are  saving  money  (e.g.,  by  using 
simulation  assets  like  simulators,  intelligent  agents  in  combination  with  physical  resources),  time  (e.g., 
units  get  ready  faster  for  a  certain  culture/environment/operation),  diminishing  environmental  impact  (e.g., 
use  of  flight  simulators  instead  of  aircrafts  to  train  tactical  behaviour),  increased  safety  (e.g.,  increased 
survivability  of  both  own  units  and  population  in  crisis  area),  security  (e.g.,  in  a  acquisition  process 
country  A  does  not  want  to  give  insight  into  a  certain  simulation  model  of  an  aircraft  to  country  B  but  it 
allows  its  remote  use  in  a  distributed  simulation). 

Finally,  the  modern  armed  forces,  especially  peacekeeping  units,  usually  face  long  lasting,  low  intensity 
campaigns.  In  such  settings,  there  are  two  concurrent  forces:  the  need  to  keep  relatively  high  alert  levels, 
and  in  the  same  time  having  a  good  troop  proficiency  training  schedule.  This  dictates  the  possibility  to 
safely  conduct  simulated  training,  tactics  development  and  experimentation,  while  part  of  the  system 
remains  operational.  The  need  is  to  switch  between  combat  readiness  by  training  with  the  operational 
equipment  and  combat  alert,  thus  safety  and  speed  of  recovery  should  be  considered. 

From  a  Modelling  &  Simulation  perspective  distributed  simulations  for  combined  operations  are  complex, 
since  multiple  simulations  standards  usually  are  used,  different  operational  levels  require  different 
aggregation  levels,  i.e.  whether  the  forces  are  handled  as  single  units  or  battalions,  use  of  both  live,  virtual 
and  constructive  (L-V-C)  simulations,  handling  communication  simulation  and  design,  planning, 
execution  and  evaluation  of  the  distributed  simulations. 

2.3  Needs  and  requirements 

The  EU  Core  Technical  Framework  (CTF)  addresses  the  participating  member  states  need  for: 

•  Collaborative  work 

•  Interoperability 

•  Reuse  of  simulation  assets 

•  Use- worthiness  focusing  on  efficiency,  effectiveness  and  satisfaction  in  aspects  of  cost,  time, 
shared  resources  and  impacts 

•  Security  that  takes  account  of  security  policies,  information  zones  and  levels  etc 

•  Flexibility,  openness,  scalability  and  modularity 
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The  CTF  is  a  descriptive  text  document,  not  prescriptive.  It  describes  a  set  of  methodologies,  processes, 
state  of  the  art  paradigms,  applicable  practices  and  recommendations  in  order  to  support  distributed 
simulation  for  CD&E,  SBA  and  Training. 

2.4  Approach 

The  Core  Technical  Framework  (CTF)  takes  legacy,  mandatory  and  upcoming  standards,  into  account 
when  developing  and  using  distributed  simulations.  These  standards  span  a  number  of  modelling  and 
simulation  standards  like  High  Fevel  Architecture  (HFA),  Distributed  Interactive  Simulation  (DIS)  and 
Test  &  Training  Enabling  Architecture  (TENA),  software  engineering  standards  like  Model  Driven 
Architecture  (MDA),  architecture  frameworks  (e.g.,  MODAF),  and  information  security  standards. 
Additionally,  the  CTF  is  oriented  towards  a  net-centric  way  of  thinking  involving  service  paradigm  and 
consistent  documentation  according  to  architecture  frameworks. 


Figure  2:  Net-centric  approach  to  distributed  simulations  [1] 


Moreover  the  CTF  supports  M&S  life  cycle  from  scenario  generation  and  experiment  planning  to 
execution  and  After  Action  Review  (AAR)  using  a  common  development  process  handling  heterogeneous 
simulation  architectures  in  an  integrated  manner. 

The  CTF  can  serve  a  wide  range  of  stakeholders  with  different  needs  and  interests,  dependency  of  work 
processes,  methods  and  technical  platforms  for  distributed  simulation. 

2.5  Core  Technical  Framework  structure  and  contents 

The  Core  Technical  Framework  (CTF)  introduced  is  composed  of  four  main  components  and  several 
subcomponents: 

•  Smorgasbord  which  is  a  collection  of  applicable  standards,  methods  and  services  from  which  the 
user  may  select  the  ones  appropriate  for  his  needs.  It  is  a  union  of  following: 

•  Architecture  framework  views  for  consistent  documentation  of  distributed  simulation 
scenarios,  assets  and  results. 

•  A  description  of  a  number  distributed  modelling  and  simulation  standards,  software 
engineering  standards  and  information  security  standards 
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•  A  service  framework  for  distributed  simulations  that  facilitate  use  of  services  from  a  net- 
centric  perspective. 

•  Reference  Model  which  consists  of  two  subcomponents: 

•  A  collection  of  most  relevant  terms  used  throughout  the  framework  and  explanations  of  them, 
i.e.  a  taxonomy. 

•  Mapping  between  some  simulation  standards  and  systems  engineering  standard. 

•  Simulation  architecture  which  describes  technical  approaches  and  high  level  design  to  support 
distributed  simulations  from  planning  to  evaluation  promoting  reuse,  resource  management  and 
automation. 

•  Methods  &  recommendations  which  describe  how  processes,  architecture  frameworks  like 
MODAF  views  and  design  recommendations  could  facilitate  development  and  reuse. 


7" 
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Figure  3:  The  structure  of  the  Core  Technical  Framework  [1] 


The  CTF  is  described  pictorially  in  Figure  3. 
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3  ARCHITECTURE  AND  ARCHITECTURE  FRAMEWORK 

3.1  Architecture 

Architecture  is  how  a  system  is  built  or  will  be  built,  whether  it  is  a  house,  a  software  system  or  a 
business.  If  you  want  to  analyse  that  system  to  see  how  to  improve  it  then  you  would  look  at  the  model  for 
that  system,  as  the  model  gives  you  a  simplified  view  of  the  system.  In  the  case  of  a  house  this  model 
could  for  example  be  building  plans  and  ventilation  charts,  for  a  business  it  could  be  process  flows  and 
organisation  charts. 

If  you  look  at  a  whole  enterprise  it  consists  of  many  different  kinds  of  activities,  organisations  and 
systems.  A  distributed  simulation  for  SBA/training/experiment  across  different  pMS  is  an  example  of  such 
an  enterprise  where  different  organisations  collaborate  in  achieving  a  mutual  goal.  It  is  often  quite 
complex  and  therefore  it  is  difficult  to  get  a  good  understanding  of  all  the  details  of  the  enterprise.  In  other 
words  it  is  not  easy  to  describe  the  architecture  of  the  enterprise.  The  problem  is  that  not  only  is  there  a 
need  to  understand  the  enterprise  and  its  architecture,  there  is  also  a  need  to  communicate  this 
understanding  to  other  parts  of  the  enterprise.  Today  this  is  often  tackled  by  creating  documents  which 
describe  and  regulate  the  business.  The  problem  with  this  approach  is  the  difficulty  to  maintain 
consistency  between  the  different  documents  and  to  find  the  areas  which  have  been  left  uncovered.  In  any 
enterprise  but  the  smallest,  this  is  in  the  end  unavoidable  with  a  document  based  approach.  The  way  to 
solve  this  problem  is  to  use  an  architecture  description  in  form  of  models  where  you  can  link  different 
areas  with  each  other  to  maintain  consistency. 

The  need  to  describe  your  architecture  is  becoming  ever  more  important  as  the  complexity  increases  due 
to  international  cooperation  and  increasing  demands  on  the  enterprise.  International  cooperation  also 
requires  common  standards  and  processes  and  it  changes  the  focus  of  standardisation  from  individual 
systems  to  interoperability  between  systems  and  organisations.  Another  reason  is  the  need  for  handling 
large  amounts  of  information  which  requires  better  structure  and  management  of  the  information  in  the 
enterprise  and  its  systems.  The  need  for  flexibility  is  high  to  be  able  to  more  quickly  adapt  to  changing 
demands,  for  example  due  to  increasing  environmental  awareness.  This  means  that  the  systems  need  to  be 
more  loosely  coupled,  as  is  the  case  in  distributed  simulations. 

There  is  a  need  for  a  framework  which  describes  how  to  use  the  different  models  and  how  they  tie 
together.  This  framework  also  needs  to  be  based  on  well  known  standard  so  as  to  be  able  to  use  experience 
from  other  enterprises  and  ensure  the  existence  of  supporting  tools  and  methods. 

3.2  Architecture  framework 

An  architecture  framework  is  a  standard  way  to  describe  architecture.  A  good  framework  will  support  the 
linkage  between  different  parts  of  the  architecture  description  so  as  to  keep  the  description  consistent  and 
clearly  show  which  parts  are  not  covered.  This  means  you  can  identify  conflicts  so  they  can  be  resolved 
and  also  enable  reuse.  It  also  supports  tracing  requirements  from  their  identification  to  how  they  were  or 
will  be  implemented  in  systems.  This  enables  validation  that  the  requirements  have  been  correctly 
implemented. 

The  framework  is  an  enabler,  and  as  such  it  creates  the  basis  for  good  architecture  descriptions,  but  it  does 
not  automatically  mean  that  all  descriptions  produced  according  to  the  framework  are  good  descriptions.  A 
framework  with  its  service  views  enables  utilization  of  different  conceptual  approaches  like  Service 
Oriented  Architecture  (SOA)  for  distributed  simulations. 
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A  good  architecture  framework  is  expected  to  support  the  following: 

•  Consistency  is  supported  by  creating  one  object  which  is  then  reused  in  different  parts  of  the 
architecture,  as  well  as  by  linkages  between  different  objects  so  that  you  can  identify  what  effect 
changes  to  an  object  will  have  to  other  objects. 

•  Traceability  is  supported  by  allowing  you  to  follow  the  effect  of  decisions  and  requirements 
through  the  architecture.  For  example  how  a  requirement  for  exchange  of  certain  type  of 
information  leads  to  the  use  of  a  particular  data  format,  e.g.  requirement  on  other  HLA  Base 
Object  Model  (BOM). 

•  Context  is  supported  by  giving  the  surrounding  of  the  sought  after  object  placing  it  in  its  context. 
For  example  by  showing  the  supporting  activities  to  exercise/SBA/experiment  management  so  as 
to  identify  outer  limits  on  those. 

•  Flexibility  is  supported  by  creating  a  well  described  surrounding  and  thus  it  is  easy  to  see  what  is 
affected  by  change  and  what  still  needs  to  be  supported  by  the  new  objects.  For  example  when 
implementing  new  services  which  will  replace  old  point  to  point  connections  it  is  possible  to 
identify  which  systems  need  to  be  able  to  access  the  new  service  that  can  be  shared  between  the 
different  stakeholders. 

•  Reuse  is  supported  by  having  a  well  defined  architecture  description  where  it  is  easier  to  find 
already  described  objects  and  reuse  them  directly  as  they  are  described  in  the  correct  way.  An 
example  of  such  an  object  could  be  a  federate  description. 

•  Understanding  of  other  architecture  descriptions  is  supported  by  having  a  well  defined 
architecture  description,  which  makes  it  easier  to  compare  other  architecture  descriptions  to  it  and 
therefore  relate  to  them. 

Currently  several  architecture  framework  approaches  are  available,  e.g.  MODAF,  DODAF,  and  NAF. 
While  some  differences  exist  between  these  approaches,  the  differences  are  of  minor  importance  from  the 
viewpoint  of  this  study.  Here  follows  description  of  views  from  NAF.  The  architecture  framework  consists 
of  views.  Each  of  the  views  presented  consist  of  sub-views. 

•  All  View  covers  the  overarching  aspects  of  an  architecture  that  relates  to  all  views.  Most 
importantly  it  covers  the  scope  of  the  architecture  description  and  the  definition  of  the  concepts 
used  in  the  architecture. 

•  Capability  View  supports  the  process  of  analysing  and  optimising  the  enterprises  capabilities.  A 
capability  is  a  high  level  description  of  the  enterprise’s  ability  to  perform  actions. 

•  Operational  View  is  a  description  of  the  tasks  and  activities,  operational  elements,  and 
information  exchanges  required  to  accomplish  business  goals. 

•  Service-Oriented  View  focuses  on  identifying  and  describing  services  it  also  captures  mapping 
of  services  to  operational  activities.  The  views  support  the  concept  of  a  Service-Oriented 
Architecture  (SOA).  An  example  of  a  service  could  be  a  discovery  service  that  finds  available  and 
suitable  federates. 

•  Systems  View  describes  systems  and  system  interconnections  providing  for,  or  supporting, 
operational  activities.  It  is  here  you  would  capture  a  common  technical  infrastructure  to  support 
the  operational  activities,  like  which  technical  artefacts  like  federates  and  technical  nodes  support 
operational  activities  of  training  /SBA/experimentation. 

•  Technical  View  is  a  set  of  rules  or  standards  to  ensure  that  a  system  satisfies  a  specified  set  of 
operational  requirements.  For  example  mandatory  standards  are  covered  by  this  view. 
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•  Programme  View  describes  how  the  capabilities  and  services  relate  to  the  various  programmes 
and  projects  being  implemented.  This  information  can  be  further  leveraged  to  show  the  impact  of 
acquisition  decisions  on  the  architecture. 

The  views  are  not  standalone  but  are  tied  together  by  a  common  model  (called  the  Meta  model)  which  is 
intended  to  ensure  consistency  between  the  different  views. 


4  SEMANTIC  MAPPINGS  AMONG  THE  M&S  AND  SE  STANDARDS 

4.1  Delimitation 

The  relations  will  be  established  by  mapping  the  products  of  the  standards  to  each  other  through  MODAF 
(to  be  precise,  MODAF  1.2)  views.  The  standards  participating  in  the  mapping  are: 

•  FEDEP  (Federation  Development  and  Execution  Process) 

•  MDA  (Model  Driven  Architecture) 

•  ISO  15288  System  Life  Cycle  Processes  Standard 

By  “products”  we  mean  the  specification  documents  from  the  standards.  In  this  sense  it  is  “product 
oriented”.  One  may  think  of  “process  oriented”  mapping  as  well,  i.e.  relating  the  phases  of  the  standard 
processes  to  each  other.  We  consider,  however,  the  product  oriented  mapping  provides  more  tangible 
output.  On  the  other  hand,  the  process  oriented  mapping  is  to  be  recommended  when,  e.g.  coordinating 
activities  of  different  stakeholders  involved  in  a  project. 

Further,  relations  are  defined  over  some  of  the  major  standards  only  by  extending  previous  results  made 
somewhere  else.  A  complete  mapping  is  beyond  the  scope  of  the  study,  because  the  mapping  is 
demonstrated  as  a  proof  of  concept.  Also,  a  major  guideline  for  this  study  was  to  reuse  the  state-of-the-art 
findings  without  reinventing  the  wheels  from  the  scratch. 

4.2  Related  work 

Connecting  architecture  framework  with  M&S  has  been  proposed  for  different  purposes  by  several 
researchers  previously.  Roughly  these  approaches  can  be  classified  in  two  groups: 

•  Using  M&S  for  architecture  framework 

•  Using  architecture  framework  for  M&S. 

In  [2]  within  the  first  group,  DoDAF  has  been  extended  with  two  new  Operational  Views  to  make  the 
DoDAF  views  compliant  with  DEVS  (Discrete  Event  System  Specification)  which  is  a  computer 
executable  formal  language.  Thereby  the  DoDAF  views  become  executable,  i.e.  they  can  be  simulated, 
e.g.  to  verify  the  consistency  of  the  view  themselves,  to  assess  and  examine  the  feasibility  of  operational 
concepts  and  operational  plans  described  in  the  views.  Similar  approach  has  been  presented  in  [3]  The 
goal  of  this  study  was  to  test  the  hypothesis  that  Executable  Architecture  (architecture  framework 
combined  with  M&S)  provides  an  effective  methodology  or  framework  to  address  and  analyze  counter¬ 
terrorism  and  homeland  security  Capability  gaps.  Another  effort  to  make  the  DoDAF  executable  was 
presented  by  [4]. 

The  work  of  [5]  is  an  approach  within  the  second  group.  This  work  was  inspiring  to  us  and  at  the  same 
time  confirmed  our  initial  ideas  concerning  the  need  of  semantic  mappings  between  and  among  M&S  and 
S/SE  standards.  Figure  4  below  shows  a  mapping  from  DoDAF  and  FEDEP  products  to  the  process  of 
MDA. 
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Figure  4:  FEDEP,  DoDAF  and  MDA  connection  [5] 

The  authors  observe  that: 

“Currently,  system  creation  is  habitually  setback  due  to  a  lack  of 
understanding  of  the  problem  space.  This  is  exacerbated  by  the 
introduction  of  capabilities  based  development,  which  demands 
interoperability,  modularity,  platform  independence,  distributed 
processing,  and  composable  capabilities.  These  requirements  can  be 
realized  through  an  alignment  of  operational  requirements  documentation 
(DoDAF)  with  a  simulation  testing  environment  (FEDEP)  in  a  platform 
independent  development  process  (MDA).  ...  Use  of  an  aligned  SE 
process  will  enhance  communication  between  architectural  developers  and 
software  experts.” 

The  mapping  identified  in  their  work,  see  Figure  4,  is  included  in  our  mapping  to  be  presented  later  in  this 
section. 


4.3  The  mapping 

The  products  of  the  M&S  and  Systems  Engineering  standards  that  are  mapped  to  the  MODAF  Views  are 
listed  below.  For  space  reason,  these  standards  and  their  products  are  not  described  in  detail  in  this  paper. 
For  detail  the  readers  are  referred  to,  e.g.  [1]. 

•  Federation  Development  and  Execution  Process  (FEDEP) 

•  Federation  Objective  (FO) 

•  Federation  Conceptual  Model  (FCM) 

•  Federation  Object  Model  (FOM) 
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•  Model  Driven  Architecture  (MDA) 

•  Computation  Independent  Model  (CIM) 

•  Platform  Independent  Model  (PIM) 

•  Platform  Specific  Model  (PSM) 

•  ISO  15288:  Outcomes  from  the  following  processes 

•  Stakeholder  Requirements  Definition  Process  (SRD) 

•  Required  characteristics  and  context  of  use  of  services 

•  Constraints  on  a  system  solution 

•  Basis  for  defining  the  system  requirements 

•  Requirement  Analysis  Process  (RA) 

•  Functional  and  performance  requirements  for  a  product  solution 

•  Constraints  affecting  the  architectural  design  and  implementation 

•  Integrity  and  traceability  of  system  requirements  to  stakeholder  requirements 

•  Architecture  Design  Process  (AD) 

•  Architecture  design  baseline 

•  Specification  of  implementable  set  of  system  elements  that  satisfy  the  system 
requirements 

•  Interface  requirements 

•  Traceability  of  architectural  design  to  system  requirements 

•  Project  Planning  Process  (PP) 

•  Project  plan 

•  Definition  of  roles,  responsibilities  and  authorities 

•  Formal  request  of  resources  and  services  necessary  to  achieve  the  project  objectives 

•  Definition  of  project  performance  measures 


The  result  of  the  mapping  is  described  in  Table  1  below.  As  mentioned  previously,  the  mapping  between 
MDA,  FEDEP  and  MODAF  are  directly  based  on  [5].3  The  readers  are  referred  to  the  paper  for  detailed 
discussion.  Definitions  of  the  MODAF  Views  and  the  products  of  the  standards  are  not  very  precise  like 
mathematical  formulae.  They  are  not  intended  to  be  so  either.  Consequently,  it  is  not  straightforward  to 
match  the  artefacts,  and  the  degree  of  matching  varies.  Furthermore  we  had  own  interpretations  and 
assumptions  in  some  places,  but  these  assumptions  and  interpretations  are  based  on  general  system 
development  principles  and  praxes.  For  example,  the  term  “capability”  in  MODAF  was  interpreted  as 
Stakeholder  needs/requirements/expectations  in  some  places,  but  also  as  “services”  somewhere  else.  Thus 
this  mapping  should  be  seen  as  a  high  level  guideline  for  identifying  related  specifications. 


3  Their  mapping  was  made  for  DODAF  Views,  but  the  difference  between  DODAF  and  MODAF  Views  concerned  is  marginal 
from  the  viewpoint  of  this  study.  They  are  considered  to  be  interchangeable. 
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Recall  that  Service  Oriented  Architecture  (SOA)  is  not  an  S/SE  standard  yet,  though  it  is  a  most 
predominant  approach  within  S/SE  today  indeed.  Thereby  no  products  are  identified  for  SOA  or  mapped 
to  MODAF  Views.  On  the  other  hand,  the  benefit  of  SOA  technology  for  distributed  simulation  has  been 
discussed  by  [6]. 


Table  1 :  MODAF  mapping  to  FEDEP,  MDA  and  ISO  15288 


MODAF  Views 

Description 

FEDEP 

MDA  & 

ISO 

15288 

Comments  on  ISO 

15288 

AV-1  Overview 
&  Summary 

Information 

An  overview  for  an  architecture 
description,  i.e.  executive-level 
summary  information  in  a 
consistent  form  that  allows  quick 
reference  and  comparison 

between  Architectures.  Includes 
assumptions,  constraints,  and 
limitations  that  may  affect  high- 
level  decisions  relating  to  the 
Architecture. 

FO 

SRD 

PP 

SRD:  System  purpose 
and  constraints  on 
system  solutions. 

PP:  Roles, 

responsibilities, 

authorities. 

AV-2  Integrated 
Dictionary 

Presents  all  the  Elements  used  in  an 
architecture  as  a  specialisation 
hierarchy,  provides  a  text  definition 
for  each  one  and  references  the 
source  of  the  element  (e.g.  MODAF 
Ontology  and  IDEAS  Model) 

Simple  definitions  of  the 
key  terms  are  provided 
be  the  standards,  but  not 
the  modelling  elements. 

StV-1 

Enterprise 

Vision 

Describes  how  high  level  goals 
and  strategy  are  to  be  delivered  in 
capability  terms. 

SRD 

Stakeholder 

requirements  &  needs  in 
SRD  are  interpreted  as 
“high  level  goals”. 

StV-2 

Capability 

Taxonomy 

Specifies  a  hierarchy  of 

capabilities. 

SRD 

RA 

Stakeholder  needs  & 
expectations  in  SRD  are 
assumed  to  be 

decomposed. 

RA  transforms  SRD  to 
functional  and 

performance 
requirements. 
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StV-4 

Capability 

Dependencies 

Dependencies  between  planned 
capabilities. 

SRD 

RA 

Stakeholder  needs  & 
expectations  in  SRD  are 
assumed  to  be 

decomposed. 

RA  transforms  SRD  to 
functional  and 

performance 
requirements. 

StV-5 

Capability  to 
Organisation 
Deployment 
Mapping 

Shows  deployment  of  Capability 
Configurations  to  specific 

organisations. 

SRD  may  be  a  right 
place  for  this,  but  not 
prescribed  specifically. 

StV-6 

Operational 
Activity  to 

Capability 
Mapping 

Mapping  between  the  capabilities 
required  by  an  Enterprise  and  the 
operational  activities  that  those 
capabilities  support. 

SRD 

SRD  defines  a  set  of 
activity  sequences  to 
identify  all  required 
services  that  correspond 
to  anticipated 

operational  and  support 
scenarios  and 

environments. 

OV-l  (OV-la, 
OV-lb  and  OV- 
lc) 

High  level  operational  concepts 
related  to  one  or  more  missions. 
An  OV-l  describes  a  mission, 
class  of  mission,  or  scenario;  and 
highlights  the  main  operational 
elements  and  interesting  or 
unique  aspects  of  operations. 

FCM 

CIM 

SRD 

SRD  describes 

characteristics  and 

context  of  use  of 
services .  Operational 

scenarios  are  also 

covered  in  SRD. 

OV-2 

Operational 

Node 

Relationship 

Description 

Provides  the  focus  for  the  expression 
of  capability  requirements  within  an 
operational  context;  expresses  a 
capability  boundary;  defines  a 
logical  network  of  information 
flows. 

FCM 

CIM 

SRD 

Data  flow  requirements 
are  described  by  AD 
(logical  architectural 

design),  but  at  a  lower 
level  of  abstraction. 
Thus  AD  not  mapped 
here. 

OV-3 

Operational 

Information 

Exchange 

Matrix 

Operational  information  exchanges 
between  nodes. 

FCM 

CIM 

SRD 

Operational  scenarios  in 
SRD  are  assumed  to 
reflect  such  information 
exchanges. 

OV-4 

Organisational 

Relationships 

Chart 

Organisational  structures  and 

interactions. 

FCM 

CIM 

SRD 

Operational 

environment  and 

conditions  are  assumed 
to  cover  this. 
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OV-5 

Operational 
Activity  Model 

Operations  that  are  normally 
conducted  in  the  course  of 
achieving  a  mission  or  a  business 
goal.  It  describes  operational 
activities  (or  tasks),  Input/Output 
flows  between  activities  and 
to/from  activities  that  are  outside 
the  scope  of  the  Architecture. 

SRD 

OV-6a 

Operational 

Rules  Model 

Operational  or  business  rules  that 
are  constraints  on  the  way  that 
business  is  done  in  the  enterprise. 

The  constraints 

described  in  SRD  are 
about  system  solution. 

OV-6b 

Operational 

State  Transition 
Description 

A  graphical  method  of  describing 
how  an  Operational  Node  or  activity 
responds  to  various  events  by 
changing  its  state. 

FCM 

CIM 

RA 

AD 

The  behaviour  of  system 
and  system  elements  are 
described  by  RA  resp. 
AD.  Graphical 

description  is  not 

prescribed. 

OV-6c 

Operational 

Event-Trace 

Description 

A  time-ordered  examination  of  the 
information  exchanges  between 
participating  Operational  Nodes  as  a 
result  of  a  particular  scenario.  Each 
event-trace  diagram  will  have  an 
accompanying  description  that 
defines  the  particular  scenario  or 
situation. 

FCM 

CIM 

SRD 

Generally  accepted  way 
of  modelling.  Can  be 
used  for  operational 
scenarios  in  SRD. 

OV-7 

Information 

Model 

The  structure  of  an  Architecture 
domain’s  information  types  and  the 
structural  business  process  rules. 

PIM 

RA 

RA  describes  required 
characteristics  and 

attributes  for  a  product 
solution. 

SV-1  Resource 

Interaction 

Specification 

The  composition  and  interaction  of 
resources  (systems,  posts, 

organisations,  software). 

PIM 

AD 

AD  defines  interfaces 
between  system 

elements.  Assumed  to 
be  covered  by  or 
derived  from  AD. 

SV-3  Resource 
Interaction 

Matrix 

A  tabular  summary  of  the  resource 
interactions  specified  in  the  SV-1 

PIM 

AD 

See  the  comments  on 
SV-1. 

SV-4 

Functionality 

Description 

The  functionality  of  resources  in  the 
architecture.  Behavioural 

counterpart  to  the  SV-1. 

PIM 

AD 

The  functions  of  system 
elements  described  in 
AD. 
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SV-6  Systems 
Data  Exchange 
Matrix 

Specifies  the  characteristics  of  the 
system  data  exchanged  between 
systems. 

AD 

AD  describes  data  flow 
requirements. 

SV-7  Resource 
Performance 
Parameters 
Matrix 

Depicts  the  performance 

characteristics  of  a  Resource  (e.g. 
system,  role  or  capability 

configuration). 

RA 

AD 

RA  and/or  AD 

depending  on  the  chosen 
level  of  abstraction. 

RA  transforms  SRD  to 
functional  and 

performance 
requirements,  which  are 
then  partitioned  into 
system  elements. 

SV-lOa 

Resource 

Constraints 

Specification 

Functional  and  non-functional 

constraints  on  the  implementation 
aspects  of  the  architecture. 

RA 

AD 

SRD  addresses 

constraints  on  a  system 
solution,  but  at  a  higher 
level. 

SV-lOb 

Resource  State 

Transition 

Description 

A  graphical  method  of  describing  a 
resource  (or  function)  response  to 
various  events  by  changing  its  state. 

PIM 

RA 

AD 

See  the  comments  on 
OV-6b. 

The  functional 

descriptions  of  RA  and 
AD  are  to  contain  this 
information. 

SV-lOc 

Resource 

Event-Trace 

Description 

A  time-ordered  examination  of  the 
interactions  between  resources.  Each 
event-trace  diagram  will  have  an 
accompanying  description  that 
defines  the  particular  scenario  or 
situation. 

FOM 

PSM 

AD 

See  the  comments  on 
SV-1. 

SV-ll  Physical 
Schema 

Defines  the  structure  of  the  various 
kinds  of  system  data  that  are  utilised 
by  the  systems  in  the  Architecture 

FOM 

PSM 

AD 

Data  flow  requirements 
in  AD  are  assumed  to 
cover  this. 

SV-12  Service 
Provision 

Specifies  configurations  of  resources 
that  can  deliver  a  service.  Provides 
the  mapping  from  services  to  the 
resources  that  provide  those 
services. 

AD 

System  functions  are 
partitioned  and  allocated 
to  system  elements  in 
AD.  Note  the  notion  of 
function  in  AD  and  that 
of  service  in  MODAF 
may  overlap  but  are  not 
the  same. 

AcV-1 

Acquisition 

Clusters 

Represents  an  organisational 

perspective  on  programmes. 

PP 

PP  defines  necessary 
roles,  authorities, 

resources  for  a  project. 
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5  FINAL  REMARKS 

This  paper  addressed  a  part  of  the  results  obtained  from  the  EU  Core  Technical  Framework  Study  which  is 
a  first  step  to  create  an  EU-wide  simulation  framework  to  support  effective  use  of  distributed  simulations 
in  a  multi-national  and  heterogeneous  environment.  A  basic  approach  taken  was  not  to  rely  on  one  single 
simulation  architecture  or  one  single  standard.  Instead,  in  order  to  support  heterogeneous  distributed 
simulations,  the  framework  should  offer  a  smorgasbord  of  standards  and  services  that  could  be  selected. 

The  semantic  mapping  among  the  M&S  and  Systems  Engineering  standards  is  a  subcomponent  of  the 
proposed  smorgasbord.  The  mapping  has  been  made  between  the  specification  documents  produced  from 
the  standards.  Such  a  mapping  contributes  to  increasing:  communication  between  different  stakeholders, 
reuse  of  M&S  artefacts  and  interoperability. 

Different  products  of  the  standards  and  the  MODAF  views  are,  by  nature,  not  defined  very  precise  like 
mathematical  formulae.  Further  different  aspects  these  products  and  views  are  intended  to  describe  are  not 
clear-cut  either,  which  is  also  in  the  nature  of  the  things.  Consequently,  it  is  not  straightforward  to  match 
the  artefacts,  and  the  degree  of  matching  varies.  In  some  places  it  was  necessary  to  make  own 
interpretations  and  assumptions,  following  general  system  development  principles  and  practice.  Thus  this 
mapping  should  be  seen  as  a  high  level  guideline  for  identifying  related  specifications. 

In  the  future  the  mapping  needs  to  go  deeper  and  be  extended  to  cover  other  M&S  standards,  e.g. 
Distributed  Simulation  Engineering  and  Execution  Process  (DSEEP)  and  Military  Scenario  Definition 
Language  (MSDL),  and  SE  standards,  e.g.  Service  Oriented  Architecture  (SOA)  if/when  it  is  established 
as  a  standard.  In  addition  the  proposed  mapping  needs  to  be  evaluated  in  practice  and  stabilised. 
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